Profile-based routing and traffic engineering

We present a new algorithm and framework for dynamic routing of bandwidth-guaranteed flows. The problem is motivated by the need to set up bandwidth-guaranteed paths in carrier and ISP networks dynamically. Traditional routing algorithms such as minimum-hop or widest-path routing do not take advantage of any knowledge about the traffic distribution or ingress-egress pairs, and therefore can often lead to severe network underutilization. Our work is inspired by the recently proposed “minimum interference routing” algorithm (MIRA) of Kodialam and Lakshman, but it improves on their approach in several ways. Our main idea is to use a “traffic profile” of the network, obtained by measurements or service-level agreements as a rough predictor of the future traffic distribution. We use this profile to solve a multicommodity network flow problem, whose output is used both to guide our online path-selection algorithm as well as to impose admission control. The offline multi-commodity solution seems very effective at distributing the routes and avoiding bottlenecks around hot spots. In particular, our algorithm can anticipate a flow’s blocking effect on groups of ingress-egress pairs, whereas MIRA only considers one ingress-egress pair at a time. Our simulation results show that the new algorithm outperforms shortest-path, widestpath, and minimum interference routing algorithms on several metrics, including the fraction of requests routed and the fraction of requested bandwidth routed. Finally, the framework is quite general and can be extended in numerous ways to accommodate a variety of traffic management priorities in the network. Keyword: We present a new algorithm and framework for dynamic routing of bandwidth-guaranteed flows. Our algorithm is online, meaning that it routes requests one at a time, without specific knowledge of future demands. We use quasi-static information about the network and traffic to select paths so as to minimize the number of requests that are rejected or the network bandwidth that is wasted. Clearly, if no assumptions are made about the flow requests, Initial work performed at Washington University in St. Louis, partially supported by NSF grant ANI 9813723. An earlier version of this paper was presented at QoFIS 2001 [SWW01]. Addresses: S. Suri, UC Santa Barbara, Santa Barbara CA 93106, USA; [email protected]. M. Waldvogel and D. Bauer, IBM Zurich Research Laboratory, 8803 Rüschlikon, Switzerland; {mwl,dnb}@zurich.ibm.com. P.R. Warkhede, Cisco Systems, San Jose CA 95134, USA; [email protected]. Reprinted from Computer Communications, volume 25, copyright 2002, with permission from Elsevier Science. a pathologically chosen set of requests can foil any online algorithm. We make minimal assumptions that are justifiable in practice and lead to a significant improvement in network utilization. In particular, we assume that the ingress and egress nodes in the network are known, and that a traffic profile between pairs of ingress-egress nodes is also known. This traffic profile can be measured, inferred from servicelevel agreements (SLAs), created by rule-of-thumb or any other mechanism suitable to the network operator. Our algorithm uses this quasi-static information in a preprocessing step (one multi-commodity flow computation), to determine certain bandwidth allocations on the links of the network. The online phase of the routing algorithm then routes tunnel requests using a “shortest-path” (SPF) like algorithm but with the additional information given by the preprocessing phase. The multi-commodity preprocessing phase allows the online algorithm to exercise admission control by rejecting some requests because of their blocking effects in the network. The motivation for our problem arises from the needs of service providers who must dynamically reserve bandwidthguaranteed routes in carrier and Internet Service Provider (ISP) networks. Following Kodialam and Lakshman [KL00], we will describe our algorithms in the context of setting up paths in Multi-Protocol Label-Switched (MPLS) networks, although our algorithms are applicable in other contexts as well, most notably virtual-circuit systems. MPLS networks [RVC01] allow explicit routing of packets by putting labels on them, which can then be used to forward packets along specific Label-Switched Paths (LSPs). Service providers can perform this encapsulation at the ingress routers, and then use LSPs to implement Virtual Private Networks (VPNs) [G00] or satisfy other quality-of-service (QoS) agreements with clients. At the ingress routers, packet classification [LS98, SVSW98, SSV99] can be used to map packets into “forwarding equivalence classes” by examining packet headers. This aggregation (mapping into equivalence classes) also has the potential advantage of smoothing out the bandwidth requirement across many bursty streams. In addition, the service providers can use a measurementbased mechanism to build a traffic profile for an ingressegress node pair. Such a profile can be as simple as an average bandwidth requirement over a certain time period. An LSP requires set up, meaning that all the intermediate routers between the ingress and egress nodes are specified. The path is set up using a signaling protocol such as RSVP [BCS93] or LDP (Label Distribution Protocol [ADF01]). The ability to specify explicit paths for any flow gives the service providers an important tool to engineer how their traffic is routed, and thereby improve network utilization by minimizing the number of requests that are rejected when the network becomes overloaded. Current intra-domain routing schemes, which forward packets based on destination address only, do not take into account what other flows are currently, or likely to be, requested. Thus, their routing behavior is highly myopic—they will reject or drop packets and flows when the default shortestpath route becomes congested, even if an alternative path is available. Algorithms such as widest-path routing also suffer from similar problems. We therefore need better schemes for routing flow requests that take better advantage of the network infrastructure, network topology, and traffic distribution. We show that this problem is NP-Complete even in highly simplified form, but propose a novel multicommodity-based framework that eliminates many of the shortcomings of shortest-path routing, widest-path routing, and even minimum interference routing. Although we present our algorithm in the context of bandwidth guarantees, it can also perform routing based on other QoS metrics such as delay, loss etc. As pointed out by Kodialam and Lakshman [KL00], if additional constraints such as delay or loss are to be incorporated into SLAs, one can do so effectively by converting those requirements into a bandwidth requirement [GAN91]. Our framework is quite general and can be extended and generalized in multiple ways to handle additional metrics and requirements. In particular, the multi-commodity flow formulation permits a cost function, which we minimize to achieve optimal routing. To minimize the number of rejected requests, we use the simple linear cost function. A variety of non-linear cost functions can be used to handle features such as minimum guaranteed bandwidth or fairness across multiple flows. 1 Routing Requirements In this section, we briefly discuss the requirements that a flow routing algorithm must satisfy. Kodialam and Lakshman [KL00] give a detailed list of ten important criteria that a dynamic path-selection algorithm must meet. We discuss only the most important requirements here. Routing without splitting flows. It is assumed that the flow should be routed on a single path, without splitting. Many flow requests may involve traffic that is inherently unsplittable (circuit emulation or voice), and therefore it is important to route them on single paths. Thus, for each flow request, the algorithm must find a path with the desired amount of bandwidth between the ingress and egress nodes, or determine that the flow is unroutable. Online routing. We assume that the individual flow setup requests arrive online, one at a time, and the algorithm must process each request without having to know future requests. In the network provisioning and design phase, it is customary to assume that exact point-to-point demands are known. But that assumption is highly impractical for the MPLS tunnel setup problem. While we make use of the quasi-static information such as traffic profiles in our algorithm, those profiles are used only as a rough guide for the aggregate demands to be expected. Furthermore, our routing algorithm is completely online—it does not need to know anything about individual requests, their bandwidth requirements, or their time of arrival. Of course, if the actual demands in aggregate deviate significantly from the assumed profile, the performance improvement achieved by our algorithm may degrade, but that is to be expected for any online algorithm. Computational requirement. We want the pathselection algorithm to be quite fast and scalable. Individual flow setup requests are typically processed at the ingress routers or switches, which operate at very high load and have limited computing power. Thus, the computational requirement per flow setup request must be kept as low as possible. In this regard, our algorithm is just as efficient and simple as the shortest-path algorithm, and substantially faster than the Kodialam-Lakshman algorithm. The expensive part of our algorithm is the preprocessing phase, which however is run very infrequently and offline, only when the quasi-static information changes. The online algorithm runs a single breadth-first search algorithm, which is several orders of magnitude faster than the max-flow computations needed by the Minimum Interference Routing Algorithm (MIRA) [KL00]. Policy constraints. A good path selection algorithm should be able to incorporate additional policy constraints. For example, a service-level agreement may require avoiding links with certain loss rate. Similarly, SLAs may require a minimum flow acceptance guarantee; for example, over a period of one hour, flows with a total bandwidth of at least 100 Mbps must be accepted. In Section 8, we describe mechanisms to implement such policy constraints into our framework. Traffic profile. Our algorithm uses information about “expected” flows between some ingress-egress node pairs. We explain the exact form of this information later, but briefly speaking our belief is that yesterday’s traffic between an ingress-egress pair can serve as a good predictor for today’s traffic. This should be especially true in light of the fact that service providers aggregate a large number of flows, using forwarding equivalence classes, for the ingress-egress pairs. Service providers can have multiple classes per ingress-egress pair, and keep separate profiles for various classes. These profiles can either be measurement based or inferred from service-level agreements. Routing information. Finally, like shortest-path routing, our algorithm also uses only the link-state information and, like the widest-path routing algorithm, it uses some auxiliary capacity information. In order to keep the presentation simple, we describe our algorithm for the centralized route server model, although it can also be implemented in a distributed fashion. 2 Review of Existing Algorithms The most commonly used algorithm for routing LSPs is the shortest-path routing, in which the path with the least number of links between ingress and egress nodes is chosen. Each of these links has been assigned a cost or weight, to determine the link’s preference. The routing algorithm keeps track of the current residual capacity for each link,